Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: decouple Serial API Message parsing and creation #7306

Merged
merged 8 commits into from
Oct 23, 2024

Conversation

AlCalzone
Copy link
Member

@AlCalzone AlCalzone commented Oct 22, 2024

This PR follows up on #7288, but this time for the Serial API message implementations.

The Message constructor signature was changed so it exclusively deals with constructing a message instance. Parsing binary payloads now happens in the static from() methods.


List of breaking API changes:

  • The [MessageName]Options interfaces no longer extend another interface and now exclusively contain the message-specific properties required for constructing that particular instance
  • Message-specific constructors now accept a single options object of type [MessageName]Options & MessageBaseOptions.
  • The MessageDeserializationOptions interface and the gotDeserializationOptions method no longer exist
  • The DeserializingMessageConstructor interface no longer exists
  • The MessageCreationOptions type has been renamed to MessageOptions
  • Instead, message instances parse their specific payload using the new static from method, which takes a pre-parsed MessageRaw (message type, function type, binary payload) and the MessageParsingContext. All Message implementations with a custom constructor are expected to implement the from method aswell.
    To parse an arbitrary message buffer use Message.parse(buffer, context).
  • Several Message implementations had their constructor options type reworked slightly for correctness. In some cases it is now necessary to pass properties that were previously inferred.
  • The static Message methods extractPayload, getConstructor, getMessageLength and isComplete were removed.
  • The Message.options property was removed
  • The TXReport object no longer has the numRepeaters property, as this was implied by the length of the repeaterNodeIds array.
  • The ICommandClassContainer interface was replaced with the new ContainsCC interface, which indicates that something contains a deserialized CC instance.
  • The Driver.computeNetCCPayloadSize method now requires that the passed message instance contains a deserialized CC instance.
  • For messages that contain a serialized CC instance, Message.parse no longer deserializes it automatically. This has to be done in a separate step.

@AlCalzone AlCalzone changed the title refactor: split constructor and parsing for Message implementations refactor: decouple Serial API Message parsing and creation Oct 23, 2024
@AlCalzone AlCalzone marked this pull request as ready for review October 23, 2024 12:20
@AlCalzone
Copy link
Member Author

@zwave-js-bot automerge

@zwave-js-bot zwave-js-bot merged commit 7db7887 into v14 Oct 23, 2024
15 checks passed
@zwave-js-bot zwave-js-bot deleted the decouple-message branch October 23, 2024 12:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants